Unique code for token verification

ABSTRACT

A method for tokenizing credentials is disclosed. In addition to a token, a verification value can be provided for each interaction. The verification value can be generated based at least in part on a dynamic data element. The dynamic data element may be kept secret, while the verification value can be distributed for use during an interaction. When the verification value is used, it can be validated by re-creating the verification value based at least on the stored dynamic data element.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.15/368,353, filed Dec. 2, 2016, which is a non-provisional applicationof and claims the benefit of the filing date of U.S. ProvisionalApplication No. 62/263,393, filed on Dec. 4, 2015, each of which isherein incorporated by reference in its entirety for all purposes.

BACKGROUND

Systems for providing dynamic values involve shared secrets, which causepredictability problems. For example, a conventional system includes anauthentication server and a user device. A user of the user device canattempt to access an account managed by the authentication server. Theuser device generates a dynamic value based on a shared secret. The userdevice then sends the dynamic value to the authentication server. Theauthentication server uses the same shared secret to validate that thedynamic value is authentic. If the dynamic value is successfullyauthenticated, the authentication server allows the user device toaccess the account.

This shared secret is problematic, as it is either static, or dynamicbut not random. As a result, the shared secret is at risk of beingdeduced or predicted by an outsider. Additionally, the authenticationserver has the burden of distributing a shared secret to each userdevice, as well as storing a shared secret for each user device.Similarly, before being able to participate in the system, each userdevice in the system is configured to incorporate the shared secret andutilize the dynamic value.

SUMMARY

Embodiments of the invention address these and other problemsindividually and collectively. For example, embodiments enable a centralserver computer to generate a verification value and then provide theverification value to a user device (or resource provider computer). Theuser device can then submit the verification value during a transaction,and the central server computer can validate that the submittedverification value is authentic.

As a result, embodiments do not require that the user device and centralserver computer have a shared secret. This means that shared secrets donot have to be distributed, and the user device does not have to beconfigured to store or use a shared secret. Additionally, theverification value can be random.

Embodiments of the invention also allow the verification value to begenerated based on a dynamic data element. The central server computercan provide the verification value to the user device, and can forgostoring the verification value. Instead, the central server computer canstore the dynamic data element. When the verification value is used fora transaction, the central server computer can validate the verificationvalue by regenerating the verification value based on the stored dynamicdata element. Forgoing storage of the verification value improvessecurity, as the verification value is less vulnerable to hacking andcompromise. In some embodiments, the dynamic data element can be smallerthan the verification value. Accordingly, storing the dynamic dataelement instead of the verification value reduces the central servercomputer's data storage burden.

One embodiment of the invention is directed to a method. The methodcomprises receiving, by a second computer, a request for a verificationvalue associated with a transaction from a first computer. The requestincludes a token and a token requestor identifier. The method furtherincludes generating a dynamic data element and storing a record. Therecord can include the dynamic data element, the token, and the tokenrequestor identifier. The method also includes generating a firstverification value based on the dynamic data element and the token,providing the first verification value to the first computer, andreceiving a request to validate the first verification value from athird computer. The request includes the first verification value, thetoken, and the token requestor identifier. The method also comprisesidentifying the record including the dynamic data element based on thetoken and the token requestor identifier, and generating a secondverification value based on the dynamic data element, the token, and thetoken requestor identifier. The second computer determines that thesecond verification value matches the first verification value, andprovides a value credential associated with the token to the thirdcomputer.

Another embodiment of the invention is directed to a second computerconfigured to perform the above-described method.

Another embodiment of the invention is directed to a method comprisingreceiving, by a third computer, an authorization request message for atransaction from a first computer. The authorization request messageincludes a token, a token requestor identifier, and a first verificationvalue. The method also includes sending the token, the token requestoridentifier, and the first verification value to a second computer. Thesecond computer identifies a dynamic data element based on the token andthe token requestor identifier, and generates a second verificationvalue based on the dynamic data element, the token, and the tokenrequestor identifier. The second computer also determines that thesecond verification value matches the first verification value. Themethod further includes receiving a value credential associated with thetoken from the second computer, and sending the authorization requestmessage and the value credential to an authorizing entity computer. Theauthorizing entity computer then authorizes the transaction based on thevalue credential.

Another embodiment of the invention is directed to a third computerconfigured to perform the above-described method.

Further details regarding embodiments of the invention can be found inthe Detailed Description and the Figures.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a block diagram of a system according to an embodiment ofthe invention.

FIG. 2 shows a block diagram of a resource provider computer accordingto an embodiment of the invention.

FIG. 3 shows a block diagram of a transaction processing computeraccording to an embodiment of the invention.

FIG. 4 shows a block diagram of a token provider computer according toan embodiment of the invention.

FIG. 5 depicts an example of a method for generating a verificationvalue according to embodiments of the invention.

FIG. 6 shows an example of deriving encryption keys according to anembodiment of the invention.

FIG. 7 shows a flow diagram with additional steps for generating averification value according to an embodiment of the invention.

FIG. 8 depicts an exemplary record format for transmitting payment dataaccording to an embodiment of the invention.

FIG. 9 shows a flow diagram illustrating a method for incorporating averification value into a transaction process, according to embodimentsof the invention.

FIG. 10 shows a block diagram of an alternative system according to anembodiment of the invention.

DETAILED DESCRIPTION

Embodiments of the present invention are directed to using averification value to authenticate the use of a token for a transaction.For example, an access token can represent a set of access credentials,but the access token may only be accepted for a transaction ifaccompanied by an authentic verification value. Similarly, a paymenttoken can represent a set of payment credentials, but the payment tokenmay only be accepted for a transaction if accompanied by an authenticverification value.

A central token provider can generate a verification value for a certainpayment token and token requestor. Embodiments allow the verificationvalue to be generated based on the token, a dynamic data element, atoken expiration date, a token requestor ID, and/or any other suitableinformation.

The input dynamic data element can also be generated by the tokenprovider. The dynamic data element can be a unique hexadecimal value, arandom number, a counter value, a timestamp, and/or any other dynamicinformation. As a result, the verification value can have a dynamicinput, such that the verification value is also a dynamic value.

While the verification value can be provided to a token requestor foruse in a transaction, the dynamic data element is not shared. Instead itcan be stored and kept private by the token provider. The algorithm usedto generate the dynamic data element can also be kept secret, as can thealgorithm for generating the verification value. As a result, the tokenprovider may be the only entity capable of generating an authenticdynamic data element and/or verification value. For example, even if afraudster intercepts a verification value, the fraudster cannotdetermine how to produce another authentic verification value. Thefraudster may not even be able to determine the format or size of thedynamic data element, let alone generate a valid dynamic data element.

Further, the verification value is not stored by the token provider.However, the token provider can still authenticate a verification valueusing the stored dynamic data element. For example, a merchant maysubmit a payment token, a token requestor ID, a verification value,and/or any other suitable information for a transaction. The tokenprovider can then identify a stored dynamic data element associated withthe received verification value (e.g., based on the payment token, tokenrequestor ID, etc.). Then, the token provider may regenerate theverification value based on the identified dynamic data element, thereceived payment token, the received token requestor ID, and/or othersuitable information. If the regenerated verification value matches thereceived verification value, the received verification value can beconsidered valid, and the transaction can proceed. For example, thetoken provider may detokenize the payment token and provide theassociated payment credentials.

Embodiments of the invention also allow token domain restrictions to beplaced on a specific use of the payment token via the verification valueand the dynamic data element. One or more token domain controls may beassociated with the verification value and indicated in a stored recordthat is associated with the verification value (e.g., a record thatincludes the dynamic data element). As a result, when the verificationvalue is being validated, the token domain controls can also beidentified and checked. If the attempted transaction does not adhere tothe assigned token domain controls, the transaction can be denied. Thus,the approved scenarios for which the payment token is valid can befurther specified and controlled.

Embodiments of the invention provide a number of advantages. Forexample, in embodiments of the invention, the use of a verificationvalue for authenticating a payment token can be implemented withouthaving to store the verification value. For example, instead of storingthe verification value, the token provider computer can store a dynamicdata element used as input for the verification value. As a result,sensitive information that can be used to overcome security barriers(e.g., the verification value) is not stored, but an incomingverification value can still be validated by re-creating theverification value with the stored dynamic data element. Thus, securityis improved because sensitive information is not stored or vulnerable.

Further, embodiments of the invention decrease the amount of storagecapacity needed at a central token provider. This can be seen bycontrasting with alternative embodiments where a cryptogram can begenerated for each transaction by encrypting transaction-relatedinformation. In this case, the cryptogram can be submitted with thetoken for a transaction, and the cryptogram can be validated byregenerating the cryptogram with the same input information andencryption keys. However, this involves storing a cryptogram and/ormultiple encryption keys for each token transaction, as well as passinga cryptogram in authorization request messages. In some embodiments, acryptogram may be a large string of data, such as a string of 40characters. Storing cryptograms and/or specific keys for eachtransaction can create a need for a large storage database. In contrast,embodiments of the invention allow the central token provider to storeas little as a dynamic data element for each transaction. A dynamic dataelement can be 1-5 characters, or any other suitable length.Additionally, encryption keys can be derived from a master key (e.g.,instead of storing each key). Thus, the amount of stored data can bereduced.

Embodiments of the invention further improve security through animproved verification value. The dynamic data element and verificationvalue can be generated at a central token provider computer. Theverification value then can be provided to a token requestor. When theverification value is used for a transaction, the token providercomputer may be asked to validate the verification value. Accordingly,the same entity (e.g., the token provider computer) can both generatethe verification value and validate the verification. As a result, thetoken provider computer may not have to share a secret with any otherentities.

In contrast, in some conventional systems, a user device may generatethe verification value, and the token provider computer may validate theverification value. For this to work, the user device and verificationvalue may keep a shared secret, such as a shared encryption key and/or ashared algorithm for generating a verification value. Shared informationis typically, to some extent, static and/or predictable. For example, auser device may use a dynamic data element such as a time of day orcounter to generate the verification value. The token provider computercan then re-create and validate the verification value using the sametime of day or counter. While this creates a dynamic verification value,the verification value is not random. A fraudster might, in theory, beable to determine the shared secret or pattern, and then be able tocreate an authentic verification value.

As mentioned above, embodiments of the invention do not require the useof shared secrets or patterns. For example, the dynamic data elementthat is used as an input for generating the verification value inembodiments of the invention can be completely random, as this valueneed not be distributed to various devices in a distributed system.

Another advantage is that the algorithm and/or encryption keys used togenerate the verification value can also be changed, random, orotherwise unpredictable. For example, a verification value can be madedynamic and unpredictable by changing one or more factors, including theinput information (e.g., using a dynamic data element as input), thealgorithm for generating the verification value, and/or the encryptionkeys used in the algorithm. Embodiments of the invention allow one ormore of these factors to be dynamic and unpredictable. For example, insome embodiments, static information can be used as input data, but thealgorithm can vary from transaction to transaction. In otherembodiments, the encryption keys can vary, while the algorithm and inputdata can be static or predictable. In other embodiments, two or more ofthe input data, algorithm, and keys can be dynamic. Thus, embodimentsprovide a number of new techniques for generating an unpredictableverification value.

Embodiments of the invention advantageously provide all of thisfunctionality without requiring merchants or acquirers to make anysystem changes. For example, the verification value can be formatted asa Card Verification Value 2 (CVV2) or Card Verification Value (CVV)value, such that it can be included in an existing field in anauthorization request message. Thus, the merchant can accept and sendthe verification value without adjusting data fields. In contrast, otherforms of payment token control often involve updates to each entity in atransaction network. For example, a token cryptogram may be too large(e.g., too many characters) to enter into a merchant checkout page or toinclude in an authorization request message, so system changes andupdates may be needed to accommodate a token cryptogram. It is difficultand inefficient to change systemic protocols and structures at thislevel, as many different entities are involved.

Prior to discussing specific embodiments of the invention, some termsmay be described in detail.

A “credential” may be any suitable information that serves as reliableevidence of worth, ownership, identity, or authority. A credential maybe a string of numbers, letters, or any other suitable characters thatmay be present or contained in any object or document that can serve asconfirmation.

A “value credential” may be information associated with worth. Examplesof a value credential include payment credentials, information needed toobtain a promotional offer, etc.

“Payment credentials” may include any suitable information associatedwith an account (e.g., a payment account and/or payment deviceassociated with the account). Such information may be directly relatedto the account or may be derived from information related to theaccount. Examples of payment credentials may include a PAN (primaryaccount number or “account number”), user name, and an expiration date.An example of a PAN is a 16-digit number, such as “4147 0900 0000 1234.”In some embodiments, payment credentials can also include verificationvalues such as CVV (card verification value), dCVV (dynamic cardverification value), CVV2 (card verification value 2), CVC3 cardverification values, dCVV2 (dynamic card verification value 2), and/orother verification values described below.

A “token” may be a substitute value for a credential. A token may be astring of numbers, letters, or any other suitable characters. Examplesof tokens include payment tokens, access tokens, personal identificationtokens, etc.

A “payment token” may include an identifier for a payment account thatis a substitute for an account identifier, such as a primary accountnumber (PAN). For example, a token may include a series of alphanumericcharacters that may be used as a substitute for an original accountidentifier. For example, a token “4900 0000 0000 0001” may be used inplace of a PAN “4147 0900 0000 1234.” In some embodiments, a token maybe “format preserving” and may have a numeric format that conforms tothe account identifiers used in existing transaction processing networks(e.g., ISO 8583 financial transaction message format). In someembodiments, a token may be used in place of a PAN to initiate,authorize, settle or resolve a payment transaction or represent theoriginal credential in other systems where the original credential wouldtypically be provided. In some embodiments, a token value may begenerated such that the recovery of the original PAN or other accountidentifier from the token value may not be computationally derived.Further, in some embodiments, the token format may be configured toallow the entity receiving the token to identify it as a token andrecognize the entity that issued the token.

“Tokenization” is a process by which data is replaced with substitutedata. For example, a payment account identifier (e.g., a primary accountnumber (PAN)) may be tokenized by replacing the primary accountidentifier with a substitute number (e.g. a token) that may beassociated with the payment account identifier. Further, tokenizationmay be applied to any other information that may be replaced with asubstitute value (i.e., token). Tokenization may be used to enhancetransaction efficiency, improve transaction security, increase servicetransparency, or to provide a method for third-party enablement.

A “token provider” or “token service system” can include a system thatservices payment tokens. In some embodiments, a token provider canfacilitate requesting, determining (e.g., generating) and/or issuingtokens, as well as maintaining an established mapping of tokens toprimary account numbers (PANs) in a repository (e.g. token vault). Atoken provider may include or be in communication with a token vaultwhere the generated tokens are stored. The token provider may supporttoken processing of payment transactions submitted using tokens byde-tokenizing the token to obtain the actual PAN. In some embodiments, atoken service system may include a tokenization computer alone, or incombination with other computers such as a transaction processingnetwork computer. Various entities of a tokenization ecosystem mayassume the roles of the token provider. For example, payment networksand issuers or their agents may become the token provider byimplementing the token services according to embodiments of the presentinvention.

A “token domain” may indicate an area and/or circumstance in which atoken can be used. Examples of the token domain may include, but are notlimited to, payment channels (e.g., e-commerce, physical point of sale,etc.), POS entry modes (e.g., contactless, magnetic stripe, etc.), andmerchant identifiers to uniquely identify where the token can be used. Aset of parameters may be established as part of token issuance by thetoken service provider that may allow for enforcing appropriate usage ofthe token in payment transactions. The parameters may include tokendomain controls which may control or restrict the token domains forwhich a token can be used. For example, the token domain controls mayrestrict the use of the token with particular presentment modes, such ascontactless or e-commerce presentment modes. In some embodiments, thetoken domain controls may restrict the use of the token at a particularmerchant that can be uniquely identified. Some exemplary token domaincontrols may require the verification of the presence of a tokencryptogram or a verification value that is unique to a giventransaction. In some embodiments, a token domain can be associated witha token requestor.

“Token expiry date” may refer to the expiration date/time of the token.The token expiry date may be passed among the entities of thetokenization ecosystem during transaction processing to ensureinteroperability. The token expiration date may be a numeric value (e.g.a 4-digit numeric value). In some embodiments, the token expiry date canbe expressed as an time duration as measured from the time of issuance.

A “token requestor” may include an entity that requests a token. A tokenrequestor may also request verification data (e.g., a verificationvalue) associated with a token. Example token requestors can include amobile device, a user computer, a resource provider computer, an enablercomputer, and/or any other suitable entity. A token requestor may beidentified by a “token requestor identifier.” A token requestoridentifier may be a set of letters, numbers, or any other suitablecharacters for identifying a token requestor. A token requestoridentifier may be assigned to the token requestor by a token servicesystem.

A “dynamic data element” may include a value that can vary acrossdifferent scenarios. For example, a dynamic data element may be a firstvalue for a first transaction, and a second value for a secondtransaction. A dynamic data element may be one or more numbers, letters,or any other suitable characters. An example of a dynamic data elementis a unique code, such as a unique hexadecimal value or a uniquecryptographic code. A unique hexadecimal value can be a randomlygenerated value. Additional examples include a random number, anapplication transaction counter (ATC), a unique transaction number, atimestamp, a transaction amount, etc. The dynamic data element caninclude any suitable number of characters, such as 5 digits.

A “verification value” may include information for authentication. Forexample, a verification value may be associated with a specific token,and a verification value may demonstrate authentic use of a token. Averification value may include one or more numbers, letters, or anyother suitable characters. A verification value can be generateddynamically, and thus can be a dynamic value that changes for each tokentransaction. In some embodiments, a verification value may be valid fora single transaction, or for multiple transactions. In some embodiments,a verification value may be generated based on one or more dynamicinputs and/or one or more static inputs. For example, a verificationvalue can be generated using a dynamic data element, a token, a tokenexpiration date, a token requestor identifier, and/or any other suitableinformation. An example of a verification value is a dCVV2.

As used herein, a “dynamic card verification value 2” (sometimesreferred to as a “device verification value” or a “dCVV2”), may be achanging verification value. A dCVV2 can be an identifier associatedwith a payment account. For example, a dCVV2 can be a verification valuesubmitted with a payment token or payment credentials of a paymentaccount. In some embodiments, a dCVV2 may be 3, 4, 5 or more charactersin length. In some embodiments, a dCVV2 can be generated based on one ormore data elements. The inputs for a dCVV2 can includetransaction-specific information and transaction-agnostic information.For example, a dCVV2 can be generated using one or more dynamic dataelements, payment data (e.g., a token, a token expiry date, etc.),transaction data associated with a current transaction (e.g., atransaction amount, a transaction identifier, an acquirer bankidentification number (BIN), a token requestor ID, etc.), one or morecryptographic keys, a cryptogram, a digital signature, a hash value(e.g., based on transaction data), and/or any other suitableinformation.

An “authorization request message” may be an electronic message thatrequests authorization for a transaction. In some embodiments, it issent to a transaction processing computer and/or an issuer of a paymentcard to request authorization for a transaction. An authorizationrequest message according to some embodiments may comply with ISO 8583,which is a standard for systems that exchange electronic transactioninformation associated with a payment made by a user using a paymentdevice or payment account. The authorization request message may includean issuer account identifier that may be associated with a paymentdevice or payment account. An authorization request message may alsocomprise additional data elements corresponding to “identificationinformation” including, by way of example only: a service code, a CVV(card verification value), a dCVV (dynamic card verification value), aPAN (primary account number or “account number”), a payment token, auser name, an expiration date, etc. An authorization request message mayalso comprise “transaction information,” such as any informationassociated with a current transaction, such as the transaction amount,merchant identifier, merchant location, acquirer bank identificationnumber (BIN), card acceptor ID, information identifying items beingpurchased, etc., as well as any other information that may be utilizedin determining whether to identify and/or authorize a transaction.

An “authorization response message” may be a message that responds to anauthorization request. In some cases, it may be an electronic messagereply to an authorization request message generated by an issuingfinancial institution or a transaction processing computer. Theauthorization response message may include, by way of example only, oneor more of the following status indicators: Approval—transaction wasapproved; Decline—transaction was not approved; or Call Center—responsepending more information, merchant must call the toll-free authorizationphone number. The authorization response message may also include anauthorization code, which may be a code that a credit card issuing bankreturns in response to an authorization request message in an electronicmessage (either directly or through the transaction processing computer)to the merchant's access device (e.g. POS equipment) that indicatesapproval of the transaction. The code may serve as proof ofauthorization. As noted above, in some embodiments, a transactionprocessing computer may generate or forward the authorization responsemessage to the merchant.

As used herein, a “mobile device” may comprise any suitable electronicdevice that may be transported and operated by a user, which may alsoprovide remote communication capabilities to a network. Examples ofremote communication capabilities include using a mobile phone(wireless) network, wireless data network (e.g. 3G, 4G or similarnetworks), a technology for radio wireless local area networking ofdevices based on the IEEE 802.11 standards (i.e., WI-FI), a family ofwireless broadband communication standards based on the IEEE 802.16 setof standards (i.e., WI-MAX), or any other communication medium that mayprovide access to a network such as the Internet or a private network.Examples of mobile devices include mobile phones (e.g. cellular phones),PDAs, tablet computers, net books, laptop computers, personal musicplayers, hand-held specialized readers, etc. Further examples of mobiledevices include wearable devices, such as smart watches, fitness bands,ankle bracelets, rings, earrings, etc., as well as automobiles withremote communication capabilities. A mobile device may comprise anysuitable hardware and software for performing such functions, and mayalso include multiple devices or components (e.g. when a device hasremote access to a network by tethering to another device—i.e. using theother device as a modem—both devices taken together may be considered asingle mobile device).

A “server computer” may include a powerful computer or cluster ofcomputers. For example, the server computer can be a large mainframe, aminicomputer cluster, or a group of servers functioning as a unit. Inone example, the server computer may be a database server coupled to aWeb server. The server computer may be coupled to a database and mayinclude any hardware, software, other logic, or combination of thepreceding for servicing the requests from one or more client computers.

FIG. 1 shows a system 100 comprising a number of components. The system100 comprises a user device 120 operated by a user 110. The system 100further comprises a resource provider computer 130, a transport computer140, a transaction processing computer 150, an authorizing entitycomputer 160, and a token provider computer 170, each of which may beembodied by one or more computers. All of the computers and devices inthe system 100 may all be in operative communication with each otherthrough any suitable communication channel or communications network.Suitable communications networks may be any one and/or the combinationof the following: a direct interconnection; the Internet; a Local AreaNetwork (LAN); a Metropolitan Area Network (MAN); an Operating Missionsas Nodes on the Internet (OMNI); a secured custom connection; a WideArea Network (WAN); a wireless network (e.g., employing protocols suchas, but not limited to a Wireless Application Protocol (WAP), I-mode,and/or the like); and/or the like.

Messages between the computers, networks, and devices may be transmittedusing a secure communications protocol such as, but not limited to, FileTransfer Protocol (FTP); HyperText Transfer Protocol (HTTP); SecureHypertext Transfer Protocol (HTTPS), Secure Socket Layer (SSL), ISO(e.g., ISO 8583) and/or the like.

The user device 120 may be any suitable device associated with the user110. In some embodiments, the user device 120 may be a mobile device, apayment device, or a desktop computer.

The user 110 may be able to use the user device 120 to interact with theresource provider computer 130. For example, the user device 120 may beable to access a website or other information associated with theresource provider computer 130. In some embodiments, the user 110 canutilize the user device 120 for purchasing goods and/or services fromthe resource provider over the internet.

The user device 120 may store or have access to certain types of userinformation. For example, the user device 120 may store paymentcredentials such as a PAN, an address, a CVV, and an expiration date.The user device 120 may store personal information such as a name,address, email address, phone number, or any other suitable user 110identification information. In some embodiments, the user device 120 mayalso store a payment token. Some or all of this data may be securelystored via hardware (e.g., a secure element) or software (e.g., hostcard emulation or other encryption techniques). The user device 120 maybe able to use payment credentials and/or payment tokens fortransactions. For example, the user device 120 may be able to transmitpayment credentials and/or payment tokens over-the-air to the resourceprovider computer 130 during internet transactions and/or in-apptransactions. Also, the user device 120 may be able to transmit (e.g.,via near-field communication (NFC), a wireless technology standard forexchanging data between devices over short distances usingshort-wavelength radio waves (i.e., BLUETOOTH), radio frequency (RF),Quick Response (QR) code, etc.) payment credentials and/or paymenttokens to an access device (e.g., a POS terminal) during in-persontransactions.

The resource provider computer 130 may be associated with a resourceprovider, which may be an entity that can provide a resource such asgoods, services, information, and/or access. Examples of a resourceprovider include merchants, access devices, secure data access points,etc. A merchant may typically be an entity that engages in transactionsand can sell goods or services, or provide access to goods or services.

The resource provider may accept multiple forms of payment and may usemultiple tools to conduct different types of transactions. For example,the resource provider may sell goods and/or services via a website, andmay accept payments over the Internet. Also, the resource provider mayoperate a physical store and use an access device for in-persontransactions.

An example of the resource provider computer 130, according to someembodiments of the invention, is shown in FIG. 2. The resource providercomputer 130 comprises a processor 130A, a network interface 130B, atoken database 130C, and a computer readable medium 130D.

The computer readable medium 130D may comprise a token request module130E, a verification data request module 130F, a transaction processingmodule 130G, and any other suitable software module. The computerreadable medium 130D may also comprise code, executable by the processor130A for implementing a method comprising sending, by a first computer,to a second computer, a request for a verification value associated witha transaction, the request including a token and a token requestoridentifier, wherein the second computer generates a dynamic data elementand a first verification value, and wherein the second computer stores arecord including the dynamic data element, the token, and the tokenrequestor identifier; receiving the first verification value from thesecond computer; and sending an authorization request message to a thirdcomputer for a transaction, the authorization request message includingthe first verification value, the token, and the token requestoridentifier, and transaction data, wherein the third computer sends theverification value to the second computer, wherein the second computergenerates a second verification value based on the dynamic data element,the token, and the token requestor identifier, wherein the secondcomputer determines that the second verification value matches the firstverification value, and wherein the second computer provides, to thethird computer, a value credential associated with the token.

The token request module 130E may comprise code that causes theprocessor 130A to obtain a token. For example, the token request module130E may contain logic that causes the processor 130A to send a tokenrequest message to the token provider computer 170. The token requestmessage may include the user's payment credentials, a token requestor IDassociated with the resource provider, and any other suitableinformation. The token request module 130E may also include instructionsfor associating a received token with the user 110 and storing thereceived token in the token database 130C.

The verification data request module 130F may comprise code that causesthe processor 130A to obtain verification data. For example, thetransaction data request module 130F may contain logic that causes theprocessor 130A to send a verification data request message to the tokenprovider computer 170. The verification data message may include theuser's payment token (e.g., stored in the token database 130C), acorresponding token expiration date, a token requestor ID associatedwith the resource provider, and any other suitable information. In someembodiments, there may be two different token requestor IDs associatedwith the resource provider. For example, a first token requestor ID maybe used for requesting a payment token, while a second token requestorID may be used for requesting a verification value.

In some embodiments, a verification data request message may include theuser's payment credentials in addition to or instead of the paymenttoken. The transaction data request module 130F may also includeinstructions for requesting verification data (e.g., a verificationvalue) when a transaction has been initiated, and instructions forproviding the verification value for inclusion in an authorizationrequest message.

The transaction processing module 130G may comprise code that causes theprocessor 130A to process transactions. For example, the transactionprocessing module 130G may contain logic that causes the processor 130Ato receive a transaction request from the user 110 for purchasing one ormore goods or services. The transaction processing module 130G mayinclude instructions for initiating a transaction authorization process,and for finalizing a transaction so that goods and/or services can bereleased. The transaction processing module 130G may, in conjunctionwith the processor 130A, submit an authorization request messageincluding a payment token, a token expiration date, a token requestorID, a verification value, and/or any other suitable information. Thetransaction processing module 130G may also include instructions forgenerating transaction receipts and storing transaction records (e.g.,including transaction data, user information, a payment token, averification value, etc.) in a transaction database.

In some embodiments, the resource provider computer 130 may encrypt thepayment token, the token expiration date, the verification value, and/orany other suitable information sent in an authorization request message.For example, the resource provider computer 130 may encrypt the datawith a public key associated with the transaction processing computer150 or the token provider computer 170, which can in turn decrypt thedata with a corresponding private key upon receipt of the authorizationrequest message. In other embodiments, a symmetric key shared betweentwo or more of the entities in the system may be used to encrypt anddecrypt data and messages. Embodiments allow any other information andmessages to be encrypted, such as communications between the resourceprovider computer 130 and token provider computer 170 related to paymenttokens and verification values.

Referring back to FIG. 1, the transport computer 140 may be associatedwith an acquirer, which may typically be a business entity (e.g., acommercial bank) that has a business relationship with a particularmerchant or other entity. Some entities can perform both issuer andacquirer functions. Some embodiments may encompass such single entityissuer-acquirers. The transport computer 140 may be more specificallyreferred to as an acquirer computer.

The transaction processing computer 150 may be disposed between thetransport computer 140 and the authorizing entity computer 160. Thetransaction processing computer 150 may include data processingsubsystems, networks, and operations used to support and deliverauthorization services, exception file services, and clearing andsettlement services. For example, the transaction processing computer150 may comprise a server coupled to a network interface (e.g., by anexternal communication interface), and databases of information. Thetransaction processing computer 150 may be representative of atransaction processing network. An exemplary transaction processingnetwork may include VISANET. Transaction processing networks such asVISANET are able to process credit card transactions, debit cardtransactions, and other types of commercial transactions. VISANET, inparticular, includes a VIP system (Visa Integrated Payments system)which processes authorization requests and a Base II system whichperforms clearing and settlement services. The transaction processingcomputer 150 may use any suitable wired or wireless network, includingthe Internet.

An example of the transaction processing computer 150, according to someembodiments of the invention, is shown in FIG. 3. The transactionprocessing computer 150 comprises a processor 150A, a network interface150B, a transaction database 150C, and a computer readable medium 150D.

The computer readable medium 150D may comprise a transaction processingmodule 150E, a token processing module 150F, and any other suitablesoftware module. The computer readable medium 150D may also comprisecode, executable by the processor 150A for implementing a methodcomprising receiving, by a third computer, from a first computer, anauthorization request message for a transaction, the authorizationrequest message including a token, a token requestor identifier, and afirst verification value; sending, by the third computer, the token, thetoken requestor identifier, and the first verification value to a secondcomputer, wherein the second computer identifies a dynamic data elementbased on the token and the token requestor identifier, wherein thesecond computer generates a second verification value based on thedynamic data element, the token, and the token requestor identifier, andwherein the second computer determines that the second verificationvalue matches the first verification value; receiving, by the thirdcomputer, from the second computer, a value credential associated withthe token; and sending, by the third computer, the authorization requestmessage and the value credential to an authorizing entity computer,wherein the authorizing entity computer authorizes the transaction basedon the value credential.

The transaction processing module 150E may comprise code that causes theprocessor 150A to process transactions. For example, the transactionprocessing module 150E may contain logic that causes the processor 150Ato analyze transaction risk, and to forward, authorize, or rejectauthorization request messages for payment transactions. The transactionprocessing module 150E may also include instructions for storingtransaction records in the transaction database 150C. For example, thetransaction database 150C may include a record of each completedtransaction that includes transaction details (e.g. items purchased,amount, timestamp, a transaction identifier), resource providerinformation, user 110 information (e.g. a name, a phone number and/orother contact information, a payment token, an expiration date, etc.),and/or any other suitable information.

The token processing module 150F may comprise code that causes theprocessor 150A to process tokens. For example, the token processingmodule 150F may contain logic that causes the processor 150A todetokenize a payment token in an authorization request message. Forexample, the token processing module 150F may receive a payment tokenfrom the transport computer 140 and send the payment token to thetokenization computer 170 in order to request and obtain correspondingpayment credentials.

In some embodiments, the token processing module 150F may includeinstructions for recognizing a payment token in an authorization requestmessage that may be accompanied by a verification value. For example,payment tokens that can be used with a verification value (e.g., insteadof a cryptogram) may be flagged, formatted in a distinct way, orotherwise recognizable.

Referring back to FIG. 1, the authorizing entity computer 160 may beassociated with an authorizing entity, which may be an entity thatauthorizes a request. An example of an authorizing entity may be anissuer, which may typically refer to a business entity (e.g., a bank)that maintains an account for a user. An issuer may also issue andmanage a payment account associated with the user device 120.

The transaction processing computer 150, the transport computer 140, andthe authorizing entity computer 160 may operate suitable routing tablesto route authorization request messages and/or authorization responsemessages using payment credentials, merchant identifiers, or otheraccount identifiers.

The token provider computer 170 may provide tokenization services. Forexample, the token provider computer 170 may be able to provide apayment token that represents a PAN and/or other payment credentials.For example, a token request message may be sent to the token providercomputer 170, and the token provider computer 170 may then generateand/or associate a payment token with payment credentials in the tokenrequest message.

In some embodiments, the token provider computer 170 may also provideverification data or any other suitable information. For example, for acertain transaction, the token provider computer 170 may be able togenerate a verification value for use with a payment token. The tokenprovider computer 170 may be able to provide such information to theresource provider computer 130, the user device 120, and/or any othersuitable entity.

In some embodiments, the token provider computer 170 may be associatedwith or combined with the transaction processing computer 150, theauthorizing entity computer 160, the transport computer 140, or anyother suitable entity. For example, in embodiments, tokenizationservices may be provided by the authorizing entity computer 160, thetransaction processing computer 150, the transport computer 140, athird-party service provider, or any other suitable entity. Thus, thetoken provider computer 170 may be incorporated as a part of anotherentity in the system 100. In some embodiments, as shown in FIG. 1, thetoken provider computer 170 may be a separate entity.

An example of the token provider computer 170, according to someembodiments of the invention, is shown in FIG. 4. The token providercomputer 170 comprises a processor 170A, a network interface 170B, atoken record database 170C, and a computer readable medium 170D.

The computer readable medium 170D may comprise a tokenization module170E, a detokenization module 170F, a verification data generationmodule 170G, a verification data validation module 170H, and any othersuitable software module. The computer readable medium 170D may alsocomprise code, executable by the processor 170A for implementing amethod comprising receiving, by a second computer, from a firstcomputer, a request for a verification value associated with atransaction, the request including a token and a token requestoridentifier; generating, by the second computer, a dynamic data element;storing, by the second computer, a record including the dynamic dataelement, the token, and the token requestor identifier; generating, bythe second computer, a first verification value based on the rootsecurity value and the token; providing, by the second computer, thefirst verification value to the first computer; receiving, by the secondcomputer, from a third computer, a request to validate the firstverification value, the request including the first verification value,the token, and the token requestor identifier; identifying, by thesecond computer, the record including the dynamic data element based onthe token and the token requestor identifier; generating, by the secondcomputer, a second verification value based on the dynamic data element,the token, and the token requestor identifier; determining, by thesecond computer, that the second verification value matches the firstverification value; and providing, by the second computer, to the thirdcomputer, a value credential associated with the token.

The tokenization module 170E may comprise code that causes the processor170A to provide payment tokens. For example, the tokenization module170E may contain logic that causes the processor 170A to generate apayment token and/or associate the payment token with a set of paymentcredentials. A token record may then be stored in the token recorddatabase 170C indicating that the payment token is associated withcertain set of payment credentials, a certain user 110, and/or a certainresource provider (e.g., via a certain token requestor ID). In someembodiments, a static token (e.g., a token that can be used for multipletransactions) can be provided to a resource provider.

The detokenization module 170F may comprise code that causes theprocessor 170A to detokenize payment tokens. For example, thedetokenization module 170F may contain logic that causes the processor170A to identify a token record associated with a payment token in thetoken record database 170C. A set of payment credentials associated withthe payment token (as indicated in the token record) can then beidentified. In some embodiments, the detokenization module 170F mayinclude instructions to detokenize a payment token in response to adetokenization request message (e.g., received from the transactionprocessing computer 150 or any other suitable entity). In someembodiments, the detokenization module 170F may include instructions towithhold detokenized payment credentials until a verification value isvalidated.

The verification data generation module 170G may comprise code thatcauses the processor 170A to generate verification data for atransaction. For example, the verification data generation module 170Gmay contain logic that causes the processor 170A to generate averification value, a dynamic data element, and/or any other suitableverification data. The verification data generation module 170G may alsoinclude instructions for providing generated verification data to arequestor.

In some embodiments, a verification value may be cryptographicallygenerated based on a payment token, a token expiration date, a dynamicdata element, and/or a token requestor ID. In other embodiments, averification value may also or alternatively be generated based on anacquirer BIN, a CVV key, one or more additional cryptographic keys,and/or any other suitable information. An example method for generatinga verification value is described below with respect to FIGS. 5-8.

In some embodiments, the verification value may not be stored by thetoken provider computer 170. For example, the token provider computer170 may store the payment token and/or token expiration date in thetoken record database 170C, but the token provider computer 170 may notstore the verification value in the token record database 170C. In someembodiments, the verification value may be a one-time use value that isvalid for one transaction. Accordingly, a unique verification value maybe provided for each verification value request.

In some embodiments, a verification value may be formatted for inclusionin an authorization request message. For example, the verification valuemay be a string of 3, 4, or 5 digits, such that it can be placed in anexisting field of an authorization request message. In some embodiments,the verification value can be a dCVV2.

As mentioned above, the verification data generation module 170G mayalso comprise code that causes the processor 170A to generate a dynamicdata element. A dynamic data element may be used as an input whengenerating the verification value. In some embodiments, the dynamic dataelement may be different for each verification value and/or transaction.As a result, each verification value generated with a dynamic dataelement as an input may be unique.

In some embodiments, a dynamic data element may be a unique hexadecimalvalue (e.g., a 5-digit hex code). In other embodiments, a dynamic dataelement can be a random number, an ATC, or any other suitable value.

If utilized, an ATC can initially be set by the token provider computer170 to a predetermined value. Thereafter, the ATC can be incrementedwith each transaction. Alternately, the ATC may be decremented from itsinitial predetermined value with each transaction. The ATC may be avalue of any suitable length.

In some embodiments, an ATC be used as an input for generating a uniquehexadecimal value. For example, a unique hexadecimal value can becreated by encrypting and/or hashing an ATC.

In some embodiments, the verification data generation module 170G mayinclude instructions for storing a dynamic data element used forgenerating a verification value. The dynamic data element may beassociated with the token, token expiration date, and/or token requestorID and stored in the token record database 170C. The stored dynamic dataelement (along with other information associated with and stored withthe dynamic data element) can be referred to as a dynamic data elementrecord or a verification value record (even if the verification value isnot stored). This dynamic data element can be included as part of apayment token record.

Accordingly, even if a verification value is not stored, theverification value can be re-created based on the stored dynamic dataelement and other corresponding information. In some embodiments, thedynamic data element may not be provided to the token requestor, and maybe kept private and secret at the token provider computer 170.

The verification data generation module 170G may include instructionsfor associating a verification value with token domain controls. As aresult, when a token is used for a transaction and the correspondingverification value is being validated, domain controls associated withthe verification value can be checked. A verification value can beassociated with one or more token domain controls, and these domaincontrols can be indicated in a dynamic data element record. As a result,the domain controls can be stored without having to store theverification value. When a verification value is used for a transaction,the domain controls can be identified along with the dynamic dataelement during a validation process for the verification value.

As an example, a verification value can be linked to a certain tokenrequestor ID, thereby indicating that only a certain token requestor canuse the verification value and payment token. Additionally, averification value can be associated with a limited time window (e.g., 1minute, 10 minutes, 1 hour, etc.) during which a verification value isvalid. Accordingly, the verification value can expire after beingissued. Additional domain controls include restricting the transactionto a certain transaction mode (e.g., in-person transactions orinternet-based transactions), a merchant ID, an acquirer BIN, a maximumtransaction amount, an allowed range of transaction locations, and/orany other suitable domain restrictions.

The verification data validation module 170H may comprise code thatcauses the processor 170A to validate verification data for atransaction. For example, the verification data validation module 170Hmay contain logic that causes the processor 170A to determine whether averification value is authentic and being used within assigned tokendomain controls.

In some embodiments, the token provider computer 170 may receive apayment token, a token expiration date, a verification value, a tokenrequestor ID, and/or any other suitable information that has beensubmitted in an authorization request message by a resource providercomputer 130. The verification data validation module 170H may includeinstructions for using the received data and/or stored data to validatethe use of the token and verification value.

In some embodiments, the verification data validation module 170H may,in conjunction with the processor 170A, identify a dynamic data elementassociated with the verification value. The dynamic data element may bestored in a dynamic data element record in the token record database170C, and the dynamic data element may be identified based on a token, atoken expiration date, a token requestor ID, an acquirer BIN, and/or anyother suitable information that is both stored in the token recorddatabase 170C and received via the authorization request message.

In some embodiments, the token provider computer 170 can identify adynamic data element record based only on the payment token and/or tokenexpiration date. For example, the token provider computer 170 may onlyissue one verification value at a time for a given payment token.Accordingly, the token provider computer 170 may be able to identify thesingle valid dynamic data element record based solely on the paymenttoken (e.g., without the token requestor ID, ATC, etc.). In otherembodiments, the token provider computer 170 can issue multipleverification values for a given payment token, but each associateddynamic data element record can be uniquely identified based on apayment token and an ATC. In further embodiments, the token requestor IDmay be used as a tag for a dynamic data element record, and thus thetoken requestor ID can be used to identify the dynamic data elementrecord (e.g., in conjunction with the payment token, token expirationdate, and/or ATC).

The verification data validation module 170H may then, in conjunctionwith the processor 170A, regenerate the verification value based on theidentified dynamic data element and the received token, the receivedtoken expiration date, the received token requestor ID, and/or any othersuitable information. The regenerated verification value can be comparedwith the received verification value. If the values match, the receivedverification value may be considered authentic and validated.

The verification data validation module 170H may include instructionsfor checking that any domain controls associated with the verificationvalue (e.g., as indicated in the token record database) are not beingviolated by the current transaction. As a result, the token providercomputer 170 can ensure that the payment token is being used withinallowed domains.

Further, the verification data validation module 170H may includeinstructions to initiate detokenization of a payment token if certaincriteria are met. For example, if a verification value is validated andtoken domain restrictions are met, a set of payment credentialsassociated with the payment token can be retrieved and provided.

FIG. 5 depicts an example of a method for generating a verificationvalue according to embodiments of the invention. Other methods may beused in other embodiments of the invention. More specifically, thismethod can generate a dCVV2 value. Initially, a numeric string ofpredetermined length can be created. This numeric string can be createdby overlaying 501 the dynamic data element 502 over the correspondingleftmost digits of the payment token 504. In some embodiments, multipledynamic data elements can be overlaid (e.g., a unique hexadecimal value,an ATC, a time of day, a transaction amount, and/or any other suitablevalue). This numeric string can be concatenated on the right with thetoken expiration date to produce a concatenated value 506. If necessary,padding characters 508 can be concatenated 510 on the right of theconcatenated value 506 to form a numeric string 512 with a predeterminedfixed length. In a preferred embodiment, this numeric string 512 can be128-bits in length, although a numeric string of any suitable length maybe used. The padding characters 508 may consist of a stream of 0's, 1's,or any suitable other numeric value. The numeric string 512 can bebisected into two blocks of equal length, Block A 516 and Block B 518.Block A 516 can then be encrypted 521 with a first encryption key 520.The result of the encryption step 521 is Block C 522 of length equal toBlock A 516. Block C 522 may then be exclusively OR'ed (XOR) 523 withBlock B 518 resulting in Block D 524. Block D 524 can then be encrypted525 with a second encryption key 526 to produce Block E 528. Block E 528can then be decrypted 529 using a decryption key 530 to produce Block F532. Block F 532 may then be encrypted 533 using a fourth encryption key534 to produce Block G 536.

It will be apparent to one of ordinary still in the art that the firstencryption key 520, the second encryption key 526, the third encryptionkey 530 and the fourth encryption key 534 may take any suitable value.In an embodiment of the present invention, the first encryption key 520,the second encryption key 526, and the fourth encryption key 534 can beequivalent and of a different value from the third encryption key 530.Other permutations of the encryption key values utilized in themethodology of FIG. 5 are within the scope of the present invention.

In a preferred embodiment, the first encryption key 520, the secondencryption key 526, the third encryption key 530, and the fourthencryption key 534 take the value of unique keys derived from dataexisting at the token provider computer 170.

For example, each unique key can be derived from a master derivationkey. Further, a CVV key (e.g., a key used to create a CVV based on anaccount number and/or an expiration date) can also be used to create theverification value.

FIG. 6 shows the methodology for deriving two unique keys which can beutilized in the preferred embodiment. The payment token 201, a tokensequence number 202, the inverse of the payment token 203, and theinverse of the token sequence number 204 can be concatenated together tocreate a concatenated value 210. If necessary, the concatenated value210 may be padded with zeroes, or some other value 211, to create astring of a predetermined fixed length. In a preferred embodiment, theconcatenated value 210 may be 128 bits in length, although theconcatenated value is not limited to being this length. The concatenatedvalue 210 may then be encrypted 220 using the master derivation key 221as the encryption key for each encryption stage. The encryption utilizedmay include any suitable type of encryption methodology. For example,this encryption step may utilize Triple-DES encryption. The valueresulting from the encryption step 220 may be a unique derived key orUDK 230. Two additional keys, UDKA 240 and UDKB 241, can be derived fromthe UDK. The derivation of UDKA 240 and UDKB 241 from the UDK 230 maytake any form, including assigning the value of the leftmost half of theUDK 230 to UDKA 240, and assigning the value of the rightmost half ofthe UDK 230 to UDKB 241. Alternatively, the UDKA 240 may be derived byselecting alternating or other predetermined bit sequences from the UDK230 while the remaining bits are assigned to UDKB 241. Furthermore,there may be no requirement that UDKA 240 and UDKB 241 are of equallength.

FIG. 7 describes the further processing for generating the verificationvalue. Each nibble (4-bit grouping) of the value stored in Block G 536may be subjected to two separate iterative processes to evaluate thevalue of each nibble. As shown in FIG. 7, beginning with the mostsignificant (i.e. left most) digit of Block G 536 and examining eachsequential nibble, if a nibble contains a value ranging from zero tonine, inclusive, that value can be extracted 301 and placed in a newnumeric string 305, referred to herein as a holding string, byconcatenating the extracted value to the right of the previouslyextracted value, if any. The result can be that the holding stringcontains a series of values ranging from zero to nine, inclusive, whichmay appear from left to right in the holding string in the same sequencein which they appear in Block G 536.

A second evaluation can then be performed again beginning with the mostsignificant digit of Block G 536 and examining each sequential nibble.If a nibble contains a hexadecimal value ranging from ten (A) to fifteen(F), inclusive, that value may be extracted 310. The extracted value canthen be decimalized by subtracting the hexadecimal value A from theextracted value resulting in a decimalized value ranging from zero tofive 315. This decimalized value can then be concatenated on the rightto the right most value of the holding string 320.

Once all nibbles in Block G have been twice examined as described, thethree most-significant (i.e. leftmost) nibbles of the holding string maybe extracted 325. This 3-digit value can be the verification value forthe transaction. Other numbers of bits (e.g., 1 bit, 2 bits, 4 bits, 5bits, 6 bits, etc.) may be extracted from the twice-examined nibblestring to generate the verification value for a transaction.Furthermore, different nibbles, such as the rightmost nibbles, may beused as the verification value for a transaction. The three leftmostnibbles, however, represent a preferred embodiment.

Once generated, the verification value can be provided to the tokenrequestor 330. The verification value can be entered into an existingdata field for a transaction, such as a CVV data field or any othersuitable data field.

FIG. 8 depicts an exemplary record format for transmitting payment data,with the verification value embedded therein, from the resource providercomputer to the token provider computer (or from the user device to theresource provider computer). The record format of FIG. 8 can be createdby concatenating a payment token 401 with a token expiration date 402and optionally a service code 403. In a preferred embodiment, thepayment token 401 may be 16 digits long, the token expiration date 402may be four digits long, and the service code 403 may be three digitslong. However, the payment token 401, the token expiration date 402, andthe service code 403 are not limited to being these lengths. Next, in afield typically reserved for other uses, a value can be placed as anindicator 705 that a verification value has been embedded in thisrecord. The value of this indicator can be known by the resourceprovider computer (or other token requestor). Next, if being used andprovided to the token requestor, an ATC 410 can be placed in the fieldwhich may typically be reserved for PIN verification data. Finally, theverification value 415 can be concatenated on the right of the record.The remainder of the record may comprise additional discretionary data.

A method 500 according to embodiments of the invention can be describedwith respect to FIG. 9. Some elements in other Figures are also referredto. The steps shown in the method 500 may be performed sequentially orin any suitable order in embodiments of the invention. In someembodiments, one or more of the steps may be optional.

The various messages described below may use any suitable form ofcommunication. In some embodiments, a request or response may be in anelectronic message format, such as an e-mail, a short messaging service(SMS) message, a multimedia messaging service (MMS) message, a hypertexttransfer protocol (HTTP) request message, a transmission controlprotocol (TCP) packet, or a web form submission. The request or responsemay be directed to any suitable location, such as an e-mail address, atelephone number, an internet protocol (IP) address, or a uniformresource locator (URL). In some embodiments, a request or response maycomprise a mix of different message types, such as both email and SMSmessages.

At step S502, a user may cause a user device 521 to provide paymentcredentials to a resource provider computer 531. For example, the usermay provide payment credentials for a transaction, or during an accountregistration process. In other embodiments, the user may provide apayment token.

As an example, the user may input (e.g., manually type) the paymentcredentials into a checkout webpage of an ecommerce website for aninternet transaction. Alternatively, the user may provide paymentcredentials for an in-person transaction by presenting the user device521 or a payment card to an access device, such that the user device 521can transmit the payment credentials over-the-air to the access device.

As described in steps S504-S508, the resource provider computer 531 mayobtain a payment token to represent the payment credentials. Forexample, the resource provider computer 531 may want to store the user'spayment information (e.g., for use in future transactions), but may onlystore payment tokens.

At step S504, the resource provider computer 531 may send a tokenrequest message to the token provider computer 570. The token requestmessage may include the user's payment credentials (e.g., a PAN,expiration date, CVV, name, address, etc.). The token request messagemay also include information associated with the resource providercomputer 531, such as a token requestor ID, a merchant ID, a physicaladdress or IP address, an acquirer BIN, and/or any other suitableinformation.

At step S506, the token provider computer 570 may receive the user'spayment credentials from the resource provider computer 531, and thetoken provider computer 570 may generate a payment token and/or tokenexpiration date for the payment credentials. The token provider computer570 may store a record of the payment token and token expiration date ina token record database, the record indicating that the payment token isassociated with the payment credentials.

In some embodiments, the payment token may be a static token that can beused for multiple transactions. Additionally, in some embodiments, thepayment token may only be provided to the resource provider computer 531and not any other token requestor. In this case, a domain control may beassigned to the payment token specifying that only the resource providercomputer 531 is authorized to use the payment token for a transaction.The payment token may only be considered valid if accompanied by anapproved token requestor ID or other identifier associated with theresource provider computer 531.

In other embodiments, the payment token may be provided to and used bymultiple token requestors. In this case, there may be multiple tokenrequestor IDs associated with the payment token in the token recorddatabase.

At step S508, the token provider computer 570 may send a token responsemessage back to the resource provider computer 531. The token responsemessage may include the payment token, token expiration date, tokenrequestor ID, and/or any other suitable information.

At step S510, the resource provider computer 531 may store the paymenttoken and token expiration date (e.g., in a token database or userdatabase). The payment token may be associated with a user account, auser device 521 identifier, or otherwise associated with the user. As aresult, the payment token can be identified and utilized for futuretransactions between the user and resource provider. Thus, the resourceprovider computer 531 can be a card-on-file merchant that stores apayment token instead of a PAN.

At a later time, the user may desire to initiate a transaction via theuser device 521. For example, the user may use the user device 521 toaccess a merchant website associated with the resource provider computer531. At step S512, the user may select one or more goods or services atthe website, and then initiate a checkout process. Alternatively, theuser may approach a merchant POS terminal for an in-person transaction,and the user may present the user device 521 or a payment card for thetransaction.

At step S514, the resource provider computer 531 may identify thepayment token and/or token expiration date associated with the userand/or user device 521. For example, the payment token may be identifiedbased on a user account, user device identifier, a user name andaddress, or any other suitable information.

Before submitting an authorization request message for the transaction,the resource provider computer 531 may obtain a verification value foruse with the payment token for this transaction. At step S516, theresource provider computer 531 may send a verification value requestmessage to the token provider computer 570. The verification valuerequest message may include the payment token, the token expirationdate, and/or any other suitable user information or payment information.The verification value request message may also include informationabout the resource provider computer 531, such as a token requestor ID,a merchant ID, an IP address or physical address, an acquirer BIN,and/or any other suitable information.

In some embodiments, the token request and verification value requestcan be combined into one request. For example, if the resource providercomputer 531 is not a card-on-file merchant, it may not store the user'spayment token, and thus may obtain both the payment token andverification value at the same time.

At step S518, the token provider computer 570 may identify the tokenrecord in the token record database based on the payment token, tokenexpiration date, token requestor ID, acquirer BIN, and/or any othersuitable information in the verification value request message. Thetoken provider computer 570 may authenticate the request, for example,by verifying that the information in the request is valid.

The token provider computer 570 may then generate a dynamic dataelement. The dynamic data element may be a unique hexadecimal value, arandom value, an ATC, a timestamp, or any other suitable value. In someembodiments, the dynamic data element may include 5 or more digits.

The token provider computer 570 may also generate a verification value.The verification value may be generated based on the dynamic dataelement, the payment token, the token expiration date, the tokenrequestor ID, an acquirer BIN, one or more cryptographic keys, and/orany other suitable information. In some embodiments, the verificationvalue can have one or more static inputs (e.g., a payment token, anexpiration date, and a token requestor ID) and one or more dynamicinputs (e.g., a unique hex value, an ATC, a timestamp, and a transactionamount). The verification value may be a unique value (e.g., as a resultof being generated based on the dynamic data element). An examplealgorithm for generating a verification value is described above withrespect to FIGS. 5-8.

The token provider computer 570 may store the dynamic data element(e.g., in a token record or a dynamic data element record). The storeddynamic data element may be associated with the payment token, tokenexpiration date, token requestor ID, acquirer BIN, a certain timeframe,and/or any other suitable information. Some or all of this correspondinginformation can be used as tags for later identifying the dynamic dataelement. For example, the dynamic data element can be identified forvalidating a transaction based on transaction information (e.g., paymenttoken, token expiration date, token requestor ID, acquirer BIN, and/orany other suitable information) received in an authorization requestmessage.

In some embodiments, the token provider computer 570 does not store theverification value. However, token provider computer 570 may be able tore-create the verification value based on the dynamic data element, thepayment token, the token expiration date, the token requestor ID, one ormore cryptographic keys associated with the payment token, an acquirerBIN, and/or any other information used to generate the originalverification value. In some embodiments, some or all of this informationmay be stored. For example, the dynamic data element can be stored asdescribed above, and the dynamic data element can be identified and usedto validate the verification value when the verification value isreceived during a transaction. In some embodiments, some or all of thisinformation may not be stored, and instead the verification value can beregenerated based on information received with the payment token for atransaction. The cryptographic keys can be stored or generated based ona master derivation key.

The token provider computer 570 may also associate one or more domaincontrols with the verification value in order to place constraints onthe use of the verification value. This can be accomplished by storingthe domain controls in the token record database along with the dynamicdata element (e.g., in a token record or a dynamic data element record).As a result, when the dynamic data element is identified for atransaction (as described above), the domain controls for thetransaction can also be identified. In further embodiments, the domainsof a current transaction (e.g., an in-person transaction at a certainmerchant) can be used to identify the correct dynamic data element.Thus, domain controls associated with the verification value can bestored even when the verification value is not stored.

As an example of a domain control, the verification value may beassociated with a context-specific use. This can include associating theverification value with the resource provider computer's token requestorID and/or the transport computer's acquirer BIN, such that theverification value can only be used for a transaction when accompaniedby the token requestor ID and/or the acquirer BIN. The verificationvalue may also be associated with a limited lifespan (e.g., only validfor a certain period of time), a certain payment mode (e.g.,internet-based transactions or in-person transactions), a maximumtransaction amount, an actual transaction amount, and/or any othersuitable token domain.

At step S520, the token provider computer 570 may send a verificationvalue response message back to the resource provider computer 531. Theverification value response message may include the verification value,the payment token, the token expiration date, and/or any other suitableinformation. In some embodiments, the token response message may notinclude the dynamic data element. In other embodiments, the tokenresponse message may not include a first dynamic data element (e.g., aunique hexadecimal value), but the token response may include a seconddynamic data element (e.g., an ATC). Thus, a random value can be keptsecret and stored, while an ATC can be sent to the resource providercomputer 531.

At step S522, the resource provider computer 531 may generate anauthorization request message for the transaction. The authorizationrequest message may include the payment token, token expiration date,the verification value, the resource provider computer's token requestorID, transaction information (e.g., information about selected goods orservices, a transaction amount, a merchant ID), an acquirer BIN, an ATC(e.g., if received from the token provider computer 570), and/or anyother suitable information.

In some embodiments, the payment information may be included in existingauthorization request message fields. For example, the payment token maybe placed in an existing PAN field, the verification value may be placedin an existing CVV2 field, and/or the token expiration date may beplaced in an existing PAN expiration date field. Additionally, thepayment token, verification value, and any other suitable informationmay be encrypted using any suitable encryption technique (e.g., using apublic key associated with the token provider computer 570 ortransaction processing computer 550).

At step S524, the resource provider computer 530 may send theauthorization request message to the transport computer 540. At stepS526, the transport computer 540 may forward the authorization requestmessage to the transaction processing computer 550. The transactionprocessing computer 550 may then interact with the token providercomputer 570 in order to detokenize the payment token.

At step S528, the transaction processing computer 550 may send adetokenization request message to the token provider computer 570. Thedetokenization request message may include information from theauthorization request message, such as the payment token, the tokenexpiration date, the verification value, the token requestor ID, atransaction ID, an acquirer BIN, an ATC, and/or any other suitableinformation.

At step S530, the token provider computer 570 may validate theverification value. For example, the token provider computer 570 mayidentify a token record (and/or a dynamic data element record) in thetoken vault based on the payment token, the token expiration date, thetoken requestor ID, the acquirer BIN, the ATC, and/or any other suitableinformation. The token record and/or the dynamic data element record mayinclude a dynamic data element.

The token provider computer 570 may regenerate the verification valuebased on information found in the token record (or dynamic data elementrecord) and/or information received in the authorization requestmessage. For example, inputs used for generating a second verificationvalue can include the dynamic data element from the token record, aswell as the payment token, token expiration date, token requestor ID,acquirer BIN, and/or ATC from the authorization request message.

The token provider computer 570 may then compare the verification valuereceived in the authorization request message with the newly regeneratedverification value. If the two verification values match, the receivedverification value can be considered valid and authentically associatedwith the payment token.

The token provider computer 570 may also identify one or more domaincontrols associated with the verification value (e.g., as indicated inthe token record or dynamic data element record). The token providercomputer 570 may determine whether the current authorization requestmessage violates any domain controls. For example, the token providercomputer 570 can determine whether the payment token and verificationvalue are being used within an allowed timeframe, being used for atransaction underneath a maximum threshold value, being submitted by anallowed merchant, token requestor, and/or acquirer, and otherwise checkfor approved usage conditions.

The token provider computer 570 may also determine whether the receivedATC matches an expected value. For example, the token provider computer570 may have stored an ATC used to generate the verification value, andthe token provider computer 570 may expect to receive that same ATC inthe next detokenization request associated with the payment token and/ortoken requestor ID.

In some embodiments, if the verification value is validated and thedomain controls are met, the token provider computer 570 may proceed todetokenize the payment token. At step S532, the token provider computer570 may identify the PAN and/or other payment credentials associatedwith the payment token. For example, the payment credentials may bestored in the token record.

At step S534, the token provider computer 570 can send a detokenizationresponse message back to the transaction processing computer 550. Thedetokenization response message may include the payment credentials, thepayment token, a transaction ID, and/or any other suitable information.The token provider computer 570 may also increase or change an ATC tothe next incremental value.

At step S536, the transaction processing computer 550 can add thepayment credentials to the authorization request message. In someembodiments, the transaction processing computer 550 may also remove thepayment token, token expiration date, verification value, and/or anyother suitable information from the authorization request message.

At step S538, the transaction processing computer 550 may forward theaugmented authorization request message to the authorizing entitycomputer 560.

At step S540, the authorizing entity computer 560 may receive theauthorization request message and determine whether the transaction isauthorized. For example, the issuer computer 160 may determine whetheran account associated with the payment credentials has sufficient funds,as well as perform risk analysis.

At step S542, the authorizing entity computer 560 may then send anauthorization response message back to the transaction processingcomputer 550 that indicates whether the transaction is authorized.

At step S544, the transaction processing computer 550 may replace thePAN and other sensitive payment credentials in the authorizationresponse message with the payment token, the token expiration date,and/or any other suitable information. In some embodiments, thetransaction processing computer 550 may query the token providercomputer 570 for the payment token.

At step S546, the transaction processing computer 550 may forward theauthorization response message to the transport computer 540. At stepS548, the transport computer 540 may forward the authorization responsemessage to the resource provider computer 531.

At step S550, the resource provider computer 531 may release thepurchased goods and/or services. Additionally, the resource providercomputer 531 may inform the user device 120 that the transaction wassuccessfully authorized. For example, the resource provider computer 531may display a transaction success window on a website or email atransaction receipt. Settlement can happen at a later time (e.g., in abatch settlement process).

Embodiments of the invention include a number of alternatives to theabove-described system and method. For example, in some embodiments, averification value can be generated further based on transactioninformation. Additionally, in some embodiments, an ecommerce enabler canperform some transaction processing and token management functionalityon behalf of the resource provider computer. Also, in some embodiments,entities other than the resource provider computer can request andutilize a payment token and verification value. Some of the scenarioswill now be briefly described below.

As described above with respect to step S518, the verification value canbe generated based on the dynamic data element, the payment token, thetoken expiration date, the token requestor ID, and/or any other suitableinformation. In further embodiments, information related to thetransaction can also be used as inputs for generating the verificationvalue. For example, at step S516, the resource provider computer 531 mayadd a transaction amount, information about selected goods or services,a transaction ID, and/or any other suitable information to theverification value request message. The token provider computer 570 canoptionally use this additional information when generating theverification value (instead of or in addition to the above-describedinputs). Additionally, token domain controls can be assigned based onthis transaction information (e.g., a maximum transaction amount, a setof goods or services for which a verification value can be used, etc.).

As a result, the verification value can be linked with a specifictransaction. For example, at step S530, the token provider computer 570may regenerate the verification value further based on the transactioninformation (e.g., a transaction amount, information about selectedgoods or services, a transaction ID), which may have been sent via theauthorization request message. If the same transaction information isnot provided in the authorization request message, the verificationvalue may be regenerated incorrectly.

In other embodiments, the verification value may be requested before thetransaction is actually initiated. For example, the verification valuerequest message at step S516 may be sent before the transaction isinitiated at step S512. As a result, the verification value may be readyfor use when the transaction is initiated, such that transactionprocessing can occur more quickly. In this scenario, the transactioninformation may not yet be available at step S518, and thus may not beused to generate the verification value.

As mentioned above, embodiments of the invention also allow for otherentities to request payment tokens and verification values. In someembodiments, any entity that can request and/or use a token can alsorequest and/or use a verification value.

For example, a user device may be able to request a payment token and/orverification value from the token provider computer. When sending apayment token request and/or token verification request, the user devicemay include additional information such as a digital wallet identifier,a user device identifier, and/or any other suitable information.

A user device may also be able to locally store the information and useit for transactions. A user device may be able to use a payment tokenand verification value for in-person transactions by transmitting thedata (e.g., via NFC) to a nearby access device (e.g., a Point of Saledevice) for a transaction. A user device may also be able to use apayment token and verification value for over-the-air transactions(e.g., by inputting the data into a merchant checkout webpage).

Accordingly, in some embodiments, a payment token and verification valuecan be requested and utilized by a number of entities. An entity thatsends a token request message (or a verification value request message)may be referred to as a “first computer.” Accordingly, a resourceprovider computer, a user device, and an ecommerce enabler computer canbe considered examples of a first computer. In some embodiments, anentity that provides a payment token and/or a verification value may bereferred to as a “second computer.” Accordingly, the token providercomputer can be considered an example of a second computer. In someembodiments, during a transaction, a separate “third computer” mayrequest detokenization and/or token validation. A transaction processingcomputer can be considered an example of a third computer.

In a further embodiment, the tokenization services may be provided bythe transaction processing computer, or another suitable entity.Accordingly, detokenization and validation steps in S530 and S532 can beperformed by the transaction processing computer, and the messages sentin steps S528 and S534 may no longer take place.

Also, in some embodiments, other entities can query the token providercomputer for detokenization. For example, instead of the transactionprocessing computer, the authorizing entity computer or the transportcomputer can send the detokenization request message at step S528.

In some embodiments, additional entities and computers may be added tothe system. For example, FIG. 10 shows a block diagram of an alternativesystem 600 according to an embodiment of the invention. The system 600comprises components similar to those described with respect to FIG. 1,except the system 600 also includes a content publisher computer 622 andan enabler computer 625.

In the system 600, the user 610 may select and purchase a good orservice from the resource provider computer 630 through a third-partywebpage (e.g., instead of a merchant website provided by the resourceprovider computer). For example, the resource provider's goods may beshown on a content publisher computer 622 webpage, and an enablercomputer 625 may facilitate purchasing the goods directly from thelisting on the content publisher computer 622 webpage (e.g., withoutbeing redirected to a resource provider webpage).

In such a scenario, a content publisher computer 622 may be associatedwith a website provider, mobile application provider, social networkprovider (e.g., TWITTER or FACEBOOK), or any other suitable entity whichmay provide content to the user device 620 (e.g., via a website ormobile application).

An enabler computer 625 may be associated with an ecommerce enabler thatcan provide transaction enabling services. For example, the enablercomputer 625 may facilitate ecommerce transactions for the resourceprovider. Exemplary ecommerce enablers include STRIPE, BRAINTREE, andTWOTAPP. In some embodiments, the enabler computer 625 may provideinternet commerce functionality to a resource provider website. In someembodiments, the enabler computer 625 may allow the resource provider toconduct ecommerce transactions through a third-party mobile applicationor website, such as through content published by the content publishercomputer 622. For example, the resource provider computer 630 may postinformation about a product to a social network site (e.g., provided bythe content publisher computer 622). An enabler computer 625 applicationor service may be integrated into content published by the contentpublisher computer 622 such that the user 610 can purchase the productimmediately from product post, instead of being redirected to themerchant's website. For example, the user 610 may select a “buy now”icon which is hosted by the enabler computer 625 within the contentpublisher's content, and a purchase process may be initiated (e.g., thecontent publisher computer 622 may inform the enabler computer 625 thata transaction was requested).

In this scenario, the enabler computer 625 may collect a user's paymentcredentials, obtain a payment token from the token provider computer670, and/or obtain a verification value associated with the paymentcredentials on behalf of the resource provider computer 630. The enablercomputer 625 may use its own token requestor ID for requesting tokeninformation and submitting transactions, or it may use a token requestorID associated with the resource provider computer 630. In someembodiments, the enabler computer 625 may locally store a payment tokenassociated with the user 110 on behalf of the resource provider computer630.

Additionally, the enabler computer 625 can submit an authorizationrequest message to the transport computer 640 (or the resource providercomputer 630) and otherwise process the transaction on behalf of theresource provider computer 630. In some embodiments, the resourceprovider computer 630 may have registered with the enabler computer 625beforehand and provided information for processing the transaction(e.g., an acquirer BIN, a merchant ID, information about goods andservices, etc.). Further, in other embodiments, the enabler computer 625can provide information about the payment token, verification value, andtransaction to the resource provider computer 630, and the resourceprovider computer 630 can then generate and submit the authorizationrequest message.

The enabler computer 625 may also receive the authorization responsemessage on behalf of the resource provider computer 630. The enablercomputer 625 can then inform the resource provider computer 630 thatgoods can be released, and inform the user device 620 (e.g., via thecontent publisher computer 622) that the transaction was successfullyauthorized.

In some embodiments, the enabler computer 625 may provide informationabout the transaction to the resource provider computer 630, and thenthe resource provider computer 630 may itself submit the authorizationrequest message for the transaction. In this scenario, the enablercomputer 625 may provide information about the goods or servicesselected for purchase, a payment token, and/or any other suitableinformation. The enabler computer 625 may also request a verificationvalue for the transaction, and then provide the verification value tothe resource provider computer 630.

This can cause a conflict of token requestor IDs used with averification value. For example, the enabler computer's token requestorID may be used to obtain the verification value from the token providercomputer 670, while the resource provider computer's token requestor IDmay be submitted in an authorization request message for thetransaction. In other words, the token provider computer 670 may receivea first token requestor ID during the verification value requestmessage, and then receive a different second token requestor ID in thedetokenization request message. This token requestor ID discrepancy maybe grounds for rejecting the transaction.

In some embodiments, in order to allow this use-case to proceed withoutrejecting the transaction, the validation of a verification value maytake place without using the token requestor ID. The verification valuecan instead be validated based on other information and domain controls(e.g., as described above). Accordingly, in some embodiments, a paymenttoken transaction may be approved even if a second token requestor IDreceived with a verification value in an authorization request messagedoes not match a first token requestor ID used to obtain theverification value.

As mentioned above, embodiments of the invention also apply to scenariosoutside of payment transactions. For example, the user may have accesscredentials for accessing a restricted physical space (e.g., a building,venue, or event space) or restricted information (e.g., a secure onlinedatabase, a personal account).

The user's access credentials can be tokenized. For example, theresource provider computer may provide access to a restricted area orsecure information. The resource provider computer can interact with thetoken provider computer for obtaining an access token associated withthe access credentials, similar to the above description of obtaining apayment token associated with payment credentials. The resource providercomputer can locally store the access token associated with the user.

Then, when the user wishes to gain access, the resource providercomputer can obtain a verification value to submit with the accesstoken. The access token and verification value can be sent to theauthorizing entity computer that can determine whether or not to grantaccess. Also, a transaction processing computer can detokenize theaccess token, so that the access credentials can be sent to theauthorizing entity computer.

Accordingly, access credentials can similarly be protected by use of anaccess token, and the access token can be similarly authenticated via averification value. Embodiments equally apply to other suitable accountscenarios where account credentials of any suitable sort can betokenized for protection.

Embodiments of the invention have a number of advantages. For example,in embodiments of the invention, a payment token can be used to replacepayment credentials, thereby improving transaction security. If apayment token is stolen or otherwise compromised, it can be canceled andreissued without having to change the actual payment credentials. Also,in some embodiments, the payment token can only be used for one paymentchannel (e.g., one merchant), so cancelling the payment token does notinterrupt transactions for other payment channels (e.g., other merchantsthat have different payment tokens that represent the same paymentcredentials).

Embodiments of the invention also advantageously provide a verificationvalue for a transaction. In some embodiments, a payment token is notaccepted unless accompanied by an authentic verification value. As aresult, transaction security and token control are improved, as eachtransaction can be individually pre-approved, and individually verifiedbefore being authorized.

Embodiments further advantageously use a centrally-generated dynamicdata element as an input when generating a verification value. In someembodiments, while the verification value is provided to a tokenrequestor, the dynamic data element can be stored and kept secret.Further, the algorithm for generating the dynamic data element can alsobe kept secret, since it is stored at a secure central computer and notdistributed. This can lead to a verification value that is unique andthat cannot be forged. For example, a fraudster cannot guess any secretdynamic data elements stored at the token provider computer, so afraudster cannot guess or re-create any valid verification values. Ifthe fraudster were to use some random value (instead of an authenticdynamic data element) as an input for creating a fraudulent verificationvalue, the fraudulent verification value would be rejected because therewould not be an associated dynamic data element stored at the tokenprovider computer. In other words, the fraudulent verification valuewould be not be verifiable when submitted for a transaction.

Embodiments further provide an improved verification value. Since thesame entity (e.g., the token provider computer) can both generate theverification value and validate the verification, there may be no needto share a secret with any other entities. As a result, the buildingblocks for the verification value (e.g., dynamic data elements used asinput, the generation algorithm, and/or the encryption keys) can betruly random and unpredictable. Thus, the verification value can bedynamic, random, and unpredictable.

Further, embodiments allow a verification value to be used withouthaving to store the verification value (i.e., no need to store sensitivesecurity information). Instead, a dynamic data element used as input forthe verification value can be stored. Additionally, embodiments candecrease the amount of storage capacity needed at a central tokenprovider. For example, instead of storing a large cryptogram or multipleencryption keys, a smaller dynamic data element can be stored, andspecific keys can be derived when needed.

Embodiments of the invention can also advantageously place unique andvarying domain controls on different payment tokens and verificationvalues. Since the dynamic data element and other information associatedwith the verification value can be centrally stored at the tokenprovider computer, any suitable domain controls can be linked with aspecific verification value at the token provider computer. As a result,even if the verification value is not stored at the token providercomputer, domain controls can still be applied to the verificationvalue. For example, when a verification value is received for atransaction, a token record and/or dynamic data element recordassociated with the verification value can be identified, and the recordcan include domain controls associated with the verification value.

This means that a verification value cannot be used by a malicious partyfor an unapproved transaction, even if the verification value iscompromised. For example, a fraudster may attempt to use a compromisedpayment token and verification value for a fraudulent transaction.However, if the transaction does not conform to the assigned domaincontrols (e.g., taking place at an allowed merchant or within an allowedtime frame, under a certain maximum transaction amount, submitted withthe correct token requestor ID, etc.), the transaction can be denied.

In some embodiments, each verification value can be generated andprovided individually. Accordingly, domain controls can be tailored andassigned for each intended transaction. For example, the token providercomputer can assign token domain controls based on the identity of thetoken requestor, the intended transaction amount (or maximum limit), theintended merchant, and/or any other suitable transaction parameters. Asa result, each transaction can be individually controlled and limited.

Embodiments of the invention can also advantageously introduce thesemethods for controlling payment tokens through verification values anddynamic data elements without requiring the merchant computer, acquirercomputer, or issuer computer to make any changes. For example, thepayment token and verification value can be submitted according tonormal authorization procedures. The verification value can be sent inan existing “CVV” field in an authorization request message withoutmaking any formatting or procedural changes, as the verification valuecan have the same format as a CVV value. In contrast, merchant andacquirer system updates would be needed in order to accommodate tokencryptograms for online transactions. Token cryptograms typically are notformatted similarly to any other values that are already used (and canbe omitted) during transaction processing. Additional fields would beneeded for the authorization request message and for merchant checkoutwebpages, and additional protocols would be needed to accept and sendtoken cryptograms.

Further, in some embodiments, a merchant (or other token requestor) maynot need to make changes to support verification value generation. Forexample, a merchant may not have to manage a secure data storage toprotect encryption keys and cryptogram-generation algorithms. Instead,verification values can be obtained from a central entity (e.g., a tokenprovider computer).

A computer system will now be described that may be used to implementany of the entities or components described herein. Subsystems in thecomputer system are interconnected via a system bus. Additionalsubsystems include a printer, a keyboard, a fixed disk, and a monitorwhich can be coupled to a display adapter. Peripherals and input/output(I/O) devices, which can couple to an I/O controller, can be connectedto the computer system by any number of means known in the art, such asa serial port. For example, a serial port or external interface can beused to connect the computer apparatus to a wide area network such asthe Internet, a mouse input device, or a scanner. The interconnectionvia system bus allows the central processor to communicate with eachsubsystem and to control the execution of instructions from systemmemory or the fixed disk, as well as the exchange of information betweensubsystems. The system memory and/or the fixed disk may embody acomputer-readable medium.

As described, the inventive service may involve implementing one or morefunctions, processes, operations or method steps. In some embodiments,the functions, processes, operations or method steps may be implementedas a result of the execution of a set of instructions or software codeby a suitably-programmed computing device, microprocessor, dataprocessor, or the like. The set of instructions or software code may bestored in a memory or other form of data storage element which isaccessed by the computing device, microprocessor, etc. In otherembodiments, the functions, processes, operations or method steps may beimplemented by firmware or a dedicated processor, integrated circuit,etc.

Any of the software components or functions described in thisapplication may be implemented as software code to be executed by aprocessor using any suitable computer language such as, for example,Java, C++ or Perl using, for example, conventional or object-orientedtechniques. The software code may be stored as a series of instructions,or commands on a computer-readable medium, such as a random accessmemory (RAM), a read-only memory (ROM), a magnetic medium such as ahard-drive or a floppy disk, or an optical medium such as a CD-ROM. Anysuch computer-readable medium may reside on or within a singlecomputational apparatus, and may be present on or within differentcomputational apparatuses within a system or network.

While certain exemplary embodiments have been described in detail andshown in the accompanying drawings, it is to be understood that suchembodiments are merely illustrative of and not intended to berestrictive of the broad invention, and that this invention is not to belimited to the specific arrangements and constructions shown anddescribed, since various other modifications may occur to those withordinary skill in the art.

As used herein, the use of “a”, “an” or “the” is intended to mean “atleast one”, unless specifically indicated to the contrary.

What is claimed is:
 1. A method comprising: receiving, by a secondcomputer, from a first computer, a request for a verification valueassociated with a transaction, the request including a token;generating, by the second computer, a dynamic data element that is notshared with the first computer and a third computer; storing, by thesecond computer, a record including the dynamic data element and thetoken; generating, by the second computer, a first verification valuebased on the dynamic data element and the token wherein the firstverification value is formatted as a dynamic card verification value 2(dCVV2); providing, by the second computer, the first verification valueto the first computer; receiving, by the second computer, from the thirdcomputer, a request to validate the first verification value, therequest including the first verification value and the token;identifying, by the second computer, the record including the dynamicdata element based on the token; generating, by the second computer, asecond verification value based on the dynamic data element and thetoken; determining, by the second computer, whether the secondverification value matches the first verification value; and providing,by the second computer, to the third computer, a value credentialassociated with the token when the second verification value matches thefirst verification value, and not providing the value credentialassociated with the token when the second verification value does notmatch the first verification value, wherein the transaction is a paymenttransaction, and wherein the third computer sends the value credentialto an authorizing entity computer, which authorizes the paymenttransaction based on the value credential.
 2. The method of claim 1,wherein the dynamic data element is a timestamp, and wherein the firstverification value is a dynamic value.
 3. The method of claim 1, whereinthe first verification value is not stored at the second computer. 4.The method of claim 1, wherein the request for the verification valuefurther includes a token requestor identifier, wherein the stored recordfurther includes the token requestor identifier, wherein the request tovalidate the first verification value further includes the tokenrequestor identifier, and wherein the record including the dynamic dataelement is identified further based on the token requestor identifier.5. The method of claim 1, wherein the token is a substitute for aprimary account number.
 6. The method of claim 5, wherein the secondcomputer is a token provider computer.
 7. The method of claim 6, whereinthe first computer is a resource provider computer.
 8. The method ofclaim 1, wherein the dynamic data element is a random number.
 9. Asecond computer comprising: a processor device; and a non-transitorycomputer readable medium, the non-transitory computer readable mediumcomprising code, executable by the processor device, for implementing amethod comprising: receiving, from a first computer, a request for averification value associated with a transaction, the request includinga token; generating a dynamic data element that is not shared with thefirst computer and a third computer; storing a record including thedynamic data element and the token; generating a first verificationvalue based on the dynamic data element and the token wherein the firstverification value is formatted as a dynamic card verification value 2(dCVV2); providing the first verification value to the first computer;receiving, from the third computer, a request to validate the firstverification value, the request including the first verification valueand the token; identifying the record including the dynamic data elementbased on the token; generating a second verification value based on thedynamic data element and the token; determining whether the secondverification value matches the first verification value; and providing,to the third computer, a value credential associated with the token whenthe second verification value matches the first verification value, andnot providing the value credential associated with the token when thesecond verification value does not match the first verification value,wherein the transaction is a payment transaction, and wherein the thirdcomputer sends the value credential to an authorizing entity computer,which authorizes the payment transaction based on the value credential.10. The second computer of claim 9, wherein the dynamic data element isa timestamp, and wherein the first verification value is a dynamicvalue.
 11. The second computer of claim 9, wherein the firstverification value is not stored at the second computer.
 12. The secondcomputer of claim 9, wherein the request for the verification valuefurther includes a token requestor identifier, wherein the stored recordfurther includes the token requestor identifier, wherein the request tovalidate the first verification value further includes the tokenrequestor identifier, and wherein the record including the dynamic dataelement is identified further based on the token requestor identifier.13. A method comprising: receiving, by a third computer, from a firstcomputer, an authorization request message for a payment transaction,the authorization request message including a token and a firstverification value, wherein the first verification value is formatted asa dynamic card verification value 2 (dCVV2); sending, by the thirdcomputer, the token and the first verification value to a secondcomputer, wherein the second computer identifies a dynamic data elementbased on the token, wherein the dynamic data element is not shared bythe second computer with the first computer and the third computer,wherein the second computer generates a second verification value basedon the dynamic data element and the token, and wherein the secondcomputer determines whether the second verification value matches thefirst verification value and provides, to the third computer, a valuecredential associated with the token when the second verification valuematches the first verification value and does not provide the valuecredential associated with the token when the second verification valuedoes not match the first verification value; receiving, by the thirdcomputer, from the second computer, the value credential associated withthe token; and sending, by the third computer, the authorization requestmessage and the value credential to an authorizing entity computer,wherein the authorizing entity computer authorizes the paymenttransaction based on the value credential.
 14. The method of claim 13,wherein the dynamic data element is a timestamp, and wherein the firstverification value is a dynamic value.
 15. The method of claim 13,wherein the first verification value is not stored at the secondcomputer.
 16. The method of claim 13, wherein the authorization requestmessage also includes a token requestor identifier, wherein the tokenrequestor identifier is also sent to the second computer, and whereinthe second computer identifies the dynamic data element further based onthe token requestor identifier.
 17. A third computer comprising: aprocessor device; and a non-transitory computer readable medium, thenon-transitory computer readable medium comprising code, executable bythe processor device, for implementing a method comprising: receiving,from a first computer, an authorization request message for a paymenttransaction, the authorization request message including a token and afirst verification value, wherein the first verification value isformatted as a dynamic card verification value 2 (dCVV2); sending thetoken and the first verification value to a second computer, wherein thesecond computer identifies a dynamic data element based on the token,wherein the dynamic data element is not shared by the second computerwith the first computer and the third computer, wherein the secondcomputer generates a second verification value based on the dynamic dataelement and the token, and wherein the second computer determineswhether the second verification value matches the first verificationvalue and provides, to the third computer, a value credential associatedwith the token when the second verification value matches the firstverification value and does not provide the value credential associatedwith the token when the second verification value does not match thefirst verification value; receiving, from the second computer, the valuecredential associated with the token; and sending the authorizationrequest message and the value credential to an authorizing entitycomputer, wherein the authorizing entity computer authorizes the paymenttransaction based on the value credential.
 18. The third computer ofclaim 17, wherein the dynamic data element is a timestamp, and whereinthe first verification value is a dynamic value.
 19. The third computerof claim 17, wherein the authorization request message also includes atoken requestor identifier, wherein the token requestor identifier isalso sent to the second computer, and wherein the second computeridentifies the dynamic data element further based on the token requestoridentifier.